# 前言
在前一章,我们学会如何在 Kubernetes 内部署自己的第一个应用。但是在实际应用中,我们还会遇到一些特定场景:
A 用户是VIP,我怎么才能让VIP用户看到内测版本呢? 我不想停机,怎么发布新版本呢? 如何让新版本服务只开放小流量访问呢? …
显然,这些场景对于我们单纯的访问来看是无法做到的。那么有什么好办法呢?
# 什么是灰度发布
首先我们来看灰度发布。灰度发布是一种发布方式,也叫 金丝雀发布 。**起源是矿工在下井之前会先放一只金丝雀到井里,如果金丝雀不叫了,就代表瓦斯浓度高。原因是金丝雀对瓦斯气体很敏感。**这就是金丝雀发布的又来,非常形象地描述了我们的发布行为。
灰度发布的做法是:会在现存旧应用的基础上,启动一个新版应用。但是新版应用并不会直接让用户访问。而是先让测试同学去进行测试。如果没有问题,则可以将真正的用户流量慢慢导入到新版上。在这中间,持续对新版本运行状态做观察,直到慢慢切换过去,这就是所谓的A/B测试。 当然,你也可以招募一些 灰度用户, 给他们设置独有的灰度标示(Cookie,Header),来让他们可以访问到新版应用。
当然,如果中间切换出现问题,也应该将流量迅速地切换到老应用上。

# 实现方案
在上一章节,我们使用 k8s 部署了 ingress 。这里我们就利用 ingress annotations 中的 canary 配置项来实现灰度发布逻辑。
# 1. 准备新版本的 Service
在开始准备灰度之前,需要准备一套新环境以备流量切分。切换到 deployment 目录,我们新启动一套 v2 的环境配置,在这里可以将原先 v1 的配置文件,拷贝一份替换为 v2 的镜像:
cd deployment && cp v1.yaml v2.yaml
修改
v2.yaml,将Deployment Name,Service Name和匹配规则都替换为v2,并将镜像版本替换为v2
apiVersion: apps/v1
kind: Deployment
metadata:
name: front-v2
spec:
selector:
matchLabels:
app: nginx-v2
replicas: 3
template:
metadata:
labels:
app: nginx-v2
spec:
containers:
- name: nginx
image: registry.cn-hangzhou.aliyuncs.com/janlay/k8s_test:v2
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: front-service-v2
spec:
selector:
app: nginx-v2
ports:
- protocol: TCP
port: 80
targetPort: 80
type: NodePort
接着使用 kubectl apply 命令使其配置生效:
kubectl apply -f ./v2.yaml
# 2. 根据不同方案进行切分
根据
Cookie切分流量
基于 Cookie 切分流量。这种实现原理主要根据用户请求中的 Cookie 是否存在灰度标示 Cookie去判断是否为灰度用户,再决定是否返回灰度版本服务。
我们新建一个全新的 ingress 配置文件,名称叫 gary :
cd ./ingress && vim ./gray.yaml
